Creating virtual areas for realtime communications

ABSTRACT

Examples that are described herein provide systems and methods for creating virtual areas for realtime communications. Some examples provide a quick and easy process for creating a virtual area for a set of communicants and provisioning those communicants for realtime communications in the virtual area. Some examples provide a quick and easy way for a user to wrap a realtime communications framework around a network service. Through seamless integration of realtime communications (e.g., realtime audio, video, chat, screen sharing, and file transfer) in persistent virtual areas, these examples are able to enhance and improve communicants&#39; experiences with a network service relative to traditional browser based methods of collaborating on network service based projects.

CROSS-REFERENCE TO RELATED APPLICATIONS

Under 35 U.S.C. §119(e), this application claims the benefit of U.S.Provisional Application No. 61/470,938, filed Apr. 1, 2011, the entiretyof which is incorporated herein by reference.

This application relates to the following co-pending patentapplications, the entirety of each of which is incorporated herein byreference: U.S. patent application Ser. No. 12/630,973, filed Dec. 4,2009; U.S. patent application Ser. No. 12/418,243, filed Apr. 3, 2009;U.S. patent application Ser. No. 12/631,008, filed Dec. 4, 2009; U.S.patent application Ser. No. 12/631,026, filed Dec. 4, 2009; U.S. patentapplication Ser. No. 12/418,270, filed Apr. 3, 2009; U.S. patentapplication Ser. No. 12/825,512, filed Jun. 29, 2010; U.S. patentapplication Ser. No. 12/354,709, filed Jan. 15, 2009; U.S. patentapplication Ser. No. 12/509,658, filed Jul. 27, 2010; U.S. patentapplication Ser. No. 12/694,126, filed Jan. 26, 2010; U.S. patentapplication Ser. No. 13/209,812, filed Aug. 15, 2011; U.S. patentapplication Ser. No. 13/229,349, filed Sep. 9, 2011; U.S. patentapplication Ser. No. 13/399,775, filed Feb. 17, 2012; U.S. patentapplication Ser. No. 13/399,737, filed Feb. 17, 2012; U.S. ProvisionalPatent Application No. 61/563,088, filed Nov. 23, 2011; and U.S.Provisional Patent Application No. 61/603,024, filed Feb. 24, 2012.

BACKGROUND

When face-to-face communications are not practical, people often rely onone or more technological solutions to meet their communications needs.Traditional telephony systems enable voice communications betweencallers. Instant messaging (also referred to as “chat”) communicationssystems enable users to communicate text messages in real time throughinstant message computer clients that are interconnected by an instantmessage server. Some instant messaging systems and interactive virtualreality communications systems allow users to be represented byuser-controllable graphical objects (referred to as “avatars”). What areneeded are improved systems and methods for realtime networkcommunications.

DESCRIPTION OF DRAWINGS

FIG. 1 is a flow diagram of an example of a method of creating a virtualarea for realtime communications.

FIG. 2A is a flow diagram of an example of interactions between avirtual area creation service and a client network node.

FIG. 2B is a flow diagram of an example of interactions between avirtual area creation service and a client network node.

FIG. 3A is a diagrammatic view of an example of client network nodesinterfacing with a network service through web browser clientapplications.

FIG. 3B is a diagrammatic view of an example of client network nodesinterfacing with a network service and a virtual environment creationservice through virtual area based realtime communications clientapplications.

FIG. 4 is a flow diagram of an example of a method of associating anetwork service with virtual area based realtime communications.

FIG. 5 is a flow diagram of an example of interactions between a networkservice, a virtual area creation service, and a client network node.

FIG. 6 is a diagrammatic view of an example of a network communicationsenvironment that includes first and second client network nodes and avirtual area platform that includes at least one server network node.

FIG. 7A is a diagrammatic view of an example of a graphical userinterface showing a perspective view of a virtual area.

FIG. 7B is a diagrammatic plan-view of the virtual area shown in FIG. 7Athat is populated with four avatar objects.

FIG. 8 is a diagrammatic plan view of an example of a zone map.

FIGS. 9-11 are respective diagrammatic views of graphical user interfaceexamples.

DETAILED DESCRIPTION

In the following description, like reference numbers are used toidentify like elements. Furthermore, the drawings are intended toillustrate major features of exemplary embodiments in a diagrammaticmanner. The drawings are not intended to depict every feature of actualembodiments nor relative dimensions of the depicted elements, and arenot drawn to scale.

I. Definition of Terms

A “communicant” is a person who communicates or otherwise interacts withother persons over one or more network connections, where thecommunication or interaction may or may not occur in the context of avirtual area. A “user” is a communicant who is operating a particularnetwork node that defines a particular perspective for descriptivepurposes.

A “computer” is any machine, device, or apparatus that processes dataaccording to computer-readable instructions that are stored on acomputer-readable medium either temporarily or permanently. A “computeroperating system” is a software component of a computer system thatmanages and coordinates the performance of tasks and the sharing ofcomputing and hardware resources. A “software application” (alsoreferred to as software, an application, computer software, a computerapplication, a program, and a computer program) is a set of instructionsthat a computer can interpret and execute to perform one or morespecific tasks. A “data file” is a block of information that durablystores data for use by a software application.

The term “computer-readable medium” refers to any tangible,non-transitory medium capable storing information (e.g., instructionsand data) that is readable by a machine (e.g., a computer). Storagedevices suitable for tangibly embodying such information include, butare not limited to, all forms of physical, non-transitorycomputer-readable memory, including, for example, semiconductor memorydevices, such as random access memory (RAM), EPROM, EEPROM, and Flashmemory devices, magnetic disks such as internal hard disks and removablehard disks, magneto-optical disks, DVD-ROM/RAM, and CD-ROM/RAM.

A “window” is a visual area of a display that typically includes a userinterface. A window typically displays the output of a software processand typically enables a user to input commands or data for the softwareprocess. A window that has a parent is called a “child window.” A windowthat has no parent, or whose parent is the desktop window, is called a“top-level window.” A “desktop” is a system-defined window that paintsthe background of a graphical user interface (GUI) and serves as thebase for all windows displayed by all software processes.

A “data sink” (referred to herein simply as a “sink”) is any of a device(e.g., a computer), part of a device, or software that receives data.

A “data source” (referred to herein simply as a “source”) is any of adevice (e.g., a computer), part of a device, or software that originatesdata.

A “network node” (also referred to simply as a “node”) is a junction orconnection point in a communications network. Examples of network nodesinclude, but are not limited to, a terminal, a computer, and a networkswitch. A “server” network node is a host computer on a network thatresponds to requests for information or service. A “client network node”is a computer on a network that requests information or service from aserver.

A Uniform Resource Identifier (URI) is a string of characters thatidentifies a network resource.

A “network resource” is anything that can be identified by a uniformresource identifier (URI) and accessed over a network, including anelectronic document, an image, a source of information, a service,operators and operands of a mathematical equation, classes, properties,numeric values, and a collection of other resources.

A “network connection” is a link between two communicating networknodes. A “connection handle” is a pointer or identifier (e.g., a uniformresource identifier (URI)) that can be used to establish a networkconnection with a network resource. A “network communication” caninclude any type of information (e.g., text, voice, audio, video,electronic mail message, data file, motion data stream, and data packet)that is transmitted or otherwise conveyed from one network node toanother network node over a network connection.

A “communicant interaction” is any type of direct or indirect action orinfluence between a communicant and another network entity, which mayinclude for example another communicant, a virtual area, or a networkservice. Examples of types of communicant communications includecommunicants communicating with each other in realtime, a communicantentering a virtual area, and a communicant requesting access to aresource from a network service.

“Presence” refers to the ability and willingness of a networked entity(e.g., a communicant, service, or device) to communicate, where suchwillingness affects the ability to detect and obtain information aboutthe state of the entity on a network and the ability to connect to theentity.

A “realtime data stream” is data that is structured and processed in acontinuous flow and is designed to be received with no delay or onlyimperceptible delay. Realtime data streams include digitalrepresentations of voice, video, user movements, facial expressions andother physical phenomena, as well as data within the computingenvironment that may benefit from rapid transmission, rapid execution,or both rapid transmission and rapid execution, including for example,avatar movement instructions, text chat, realtime data feeds (e.g.,sensor data, machine control instructions, transaction streams and stockquote information feeds), screen shares, and file transfers.

A “virtual area” (also referred to as an “area” or a “place”) is arepresentation of a computer-managed space or scene. Virtual areastypically are one-dimensional, two-dimensional, or three-dimensionalrepresentations; although in some examples a virtual area may correspondto a single point. Oftentimes, a virtual area is designed to simulate aphysical, real-world space. For example, using a traditional computermonitor, a virtual area may be visualized as a two-dimensional graphicof a three-dimensional computer-generated space. However, virtual areasdo not require an associated visualization. A virtual area typicallyrefers to an instance of a virtual area schema, where the schema definesthe structure and contents of a virtual area in terms of variables andthe instance defines the structure and contents of a virtual area interms of values that have been resolved from a particular context.

A “virtual area application” (also referred to as a virtual areaspecification or template) is a description of a virtual area that isused in creating a virtual environment. A virtual area applicationtypically includes definitions of geometry, physics, and realtimeswitching rules that are associated with one or more zones of thevirtual area.

A “virtual area based realtime communications application” is a clientcommunications application that integrates realtime audio communications(and potentially other realtime communications, e.g., video, chat, andrealtime other data stream) with visual presentations of interactions ina virtual area.

A “virtual environment” is a representation of a computer-managed spacethat includes at least one virtual area and supports realtimecommunications between communicants.

A “position” in a virtual area refers to a location of a point or anarea or a volume in the virtual area. A point typically is representedby a single set of one-dimensional, two-dimensional, orthree-dimensional coordinates (e.g., x, y, z) that define a spot in thevirtual area. An area typically is represented by the three-dimensionalcoordinates of three or more coplanar vertices that define a boundary ofa closed two-dimensional shape in the virtual area. A volume typicallyis represented by the three-dimensional coordinates of four or morenon-coplanar vertices that define a closed boundary of athree-dimensional shape in the virtual area.

As used herein, the term “includes” means includes but not limited to,the term “including” means including but not limited to. The term “basedon” means based at least in part on.

II. Creating a Virtual Area for Realtime Communications

The examples that are described herein provide systems and methods forcreating virtual areas for realtime communications.

Some examples provide a quick and easy process for creating a virtualarea for a set of communicants and provisioning those communicants forrealtime communications in the virtual area.

FIG. 1 shows an example of a method by which a virtual area is createdby a virtual area creation service provided by a computer system (e.g.,the virtual area platform described below). In accordance with thismethod, the computer system receives from a client network node arequest to create a virtual area in connection with communicantinformation associated with one or more communicants who are to bedesignated as members of the virtual area (FIG. 1, block 330). Thecomputer system creates the virtual area based on the receivedcommunicant information (FIG. 1, block 332). In this process, thecomputer system determines a virtual area template that definesgeometric and communication properties of the virtual area, generates aunique virtual area identifier for the virtual area, and associates thecommunicant information and the virtual area template with the uniquevirtual area identifier. The computer system provides a virtual areabased realtime communications application that is installable on aclient network node and is operable to generate a graphical userinterface for displaying a visualization of the virtual area inaccordance with the virtual area template and providing interactioncontrols enabling a user to specify where to establish a presence in thevirtual area and interaction controls enabling a user to manageinteractions with one or more other communicants in the virtual area(FIG. 1, block 334).

In some examples, the communicant information includes a respectivecommunication service handle (e.g., an email address or othercommunication service username or other identifier) for each of one ormore of the communicants who are to be designated as members of thevirtual area.

In some examples, the computer system additionally provides an interfaceto the client network node for specifying the communicant information.The computer system typically connects to a directory service (e.g., anActive Directory service available from Microsoft Corporation ofRedmond, Wash. USA) that provides access to communicant informationstored in a remote network directory. In some examples, the computersystem connects to the directory service using the Lightweight DirectoryAccess Protocol (LDAP). Based on user input received from the clientnetwork node, the computer system queries the directory service forcommunicant information in the remote network directory, and transmitsresults of the querying to the client network node for presentation inthe interface. Based on user input in connection with the transmittedresults of the querying, the computer retrieves from the remote networkdirectory the communicant information associated with the one or morecommunicants who are to be designated as members of the virtual area.

In some examples, the computer system additionally generates a virtualarea reference (e.g., a URI) to the virtual area, and transmits thevirtual area reference to a particular client network node. Based onreceipt of a request to follow the reference from the particular clientnetwork node, the computer system transmits instructions for renderingan instance of the virtual area in accordance with the virtual areatemplate to an instance of the virtual area based realtimecommunications application operating on the particular network node. Insome examples, the computer system transmits the virtual area referenceto the particular client network node in association with an invitationto enter the virtual area.

FIG. 2A is a flow diagram of an example of interactions between avirtual area creation service and a client network node in a process ofcreating a virtual area.

In accordance with the flow diagram of FIG. 2A, the virtual areacreation service provides an area creation interface to the clientnetwork node (FIG. 2A, block 300). In some examples, the area creationinterface is a web page that provides a web form for entering accountcreation information and a user-activatable interface control (e.g., abutton) that can be activated by the user to send the account creationinformation to the virtual area creation service and initiate a virtualarea creation process.

Using the area creation interface, the user of the client network nodeprovides account creation information and initiates a virtual areacreation process (FIG. 2A, block 302). In some examples, a web browsercomponent of the client network node renders the area creation interfaceon a display, receives input from the user, and transmits the user input(including account creation information) to the virtual area creationservice.

The account creation information includes communicant information, whichtypically includes a list of the communicants who are to be designatedas members of the virtual area, and profile information (e.g., contactinformation, such as a communication service handle and a username) foreach of the members. The communicant information also may designaterespective ones of the communicants as owners or co-owners of particularzones (e.g., offices or other types of rooms) in the virtual area. Insome examples, the user has credentials that allow the virtual areacreation service to access the communicant information from a networkdatabase that is managed by a directory service (e.g., a Windows® ActiveDirectory service). The directory service exposes an API that allows thevirtual area creation service to query the database for communicantinformation based on used-specified input. The virtual area creationservice presents the query results to the user in the area creationinterface. The user may use the area creation interface to designatewhich of the communicants listed in the query results are members of thevirtual area. The virtual area creation service retrieves thecommunicant information for the designated members from the networkdatabase and stores the retrieved information in a database inassociation with the virtual area. In some cases, the user also is ableto upload the communicant information to the virtual area creationservice in the form of a data file (e.g., a comma separated value file).

In some examples, the account creation information also includes virtualarea information (e.g., a virtual area type, name, and size). In otherexamples, the virtual area creation service automatically selects adefault virtual area type and a size that accommodates the number ofcommunicants who are designated as members of the virtual area.

The account creation information also may include network serviceinformation. The network service information typically includes arespective reference (e.g., a URI) for one or more network services(e.g., a respective URL for a respective homepage of each networkservice or a URL for a web page tied to a particular network serviceproject associated with the user) that are to be associated withrespective objects (e.g., viewscreen objects) in the virtual area.

The virtual area creation service creates a virtual area and stores theaccount creation information in association with the virtual area (FIG.2A, block 304). In this process, the virtual area creation servicetypically generates a unique virtual area identifier for the virtualarea and a unique virtual area customization identifier for the accountinformation, and associates the account information, virtual areaidentifier, and the virtual area customization identifier in a database.In some examples, the virtual area creation service also creates anaccount and a respective account identifier for an organizationdesignated by the user (e.g., a business, social group, or otherorganization of which designated communicants are members), and aseparate account and a respective communicant identifier for each of themembers of the virtual area listed in the communicant information. Thevirtual area creation service typically associates the communicantidentifiers with the virtual area identifier (e.g., stores theidentifiers of the designated communicants in a member list for thevirtual area), and typically associates any designated network serviceswith the virtual area (e.g., by associating respective URIs for thenetwork services with respective objects in the virtual area). In someexamples, the virtual area creation service associates the virtual areaidentifier and the virtual area customization identifier with aninstallation package for a virtual area based realtime communicationsapplication (e.g., by incorporating the virtual area identifier and thevirtual area customization identifier into a link that is embedded inthe installation package).

In some examples, the virtual area creation service also allows the userto send invitations to enter the virtual area to selected ones of thecommunicants. In his process, the virtual area creation servicetypically displays contact information for the communicants who areassociated with the virtual area in an invitation dialog box associatedwith the area creation interface. The invitation dialog box typicallyincludes virtual area member fields (e.g., a member name field and afield for a member's communication service handle, such as an electronicmail address) that are pre-populated with the members' contactinformation. The invitation dialog box includes a user control (e.g., a“submit” button) that allows the user to instruct the virtual areacreation service to submit invitations to the members identified in theinvitation dialog box. Each invitation typically includes a link thatincludes the virtual area identifier and allows each invitee to installthe virtual area based realtime communications application on theinvitee's client node and to cause the installed client application tonavigate to an active instance of the virtual area or, if the clientapplication already is installed, to cause the client application tonavigate to the active instance of the virtual area. In some examples,the link in the invitation directs a browser component of an invitee'sclient network node to a landing web page provided by the virtual areacreation service for downloading the client application installationpackage to the invitee's client network node. In some examples, theinvitation links are virtual area location URLs of the type described inU.S. patent application Ser. No. 12/694,126, filed Jan. 26, 2010.

FIG. 2B is a flow diagram of an example of interactions between thevirtual area creation service and a user operating a client networknode. The user may be, for example, the same user who created thevirtual area in accordance with the process shown in FIG. 2A or one ofthe members of that virtual area.

The user downloads the client application installation package to theclient network node (FIG. 2B, block 310). A browser component of theclient network node typically navigates to the landing page (e.g., basedon a link received in an invitation to join the virtual area) anddownloads the installation package that is associated with the linkprovided by the virtual area creation service.

The user's client network node runs the installation package to installthe virtual area based realtime communications application (FIG. 2B,block 316). In this process, an installer component of the installationpackage installs the virtual area based realtime communicationsapplication, extracts the virtual area identifier and the virtual areacustomization identifier from the installation package, and sends thevirtual area identifier and the virtual area customization identifier tothe virtual area creation service.

The virtual area creation service initializes the virtual areaassociated with the virtual area customization identifier (FIG. 2B,block 316). In some examples, the virtual area creation service selectsthe designated template for the virtual area, and establishes a presencefor the user in a particular position in the virtual area.

The virtual area creation service sends a specification of the virtualarea to the user's client network node (FIG. 2A, block 318). The virtualarea creation service also typically sends the user's presence positionand any network service association information to the user's clientnetwork node. In some examples, the virtual area creation service alsosends contact information for other communicants that are identified inthe account creation information as being associated with the virtualarea.

The user's client network node runs the virtual area based realtimecommunications application, which enables realtime communications andshared interactions with other communicants in the virtual area (FIG.2B, block 320).

Some of the examples described herein provide a quick and easy way for auser to wrap a realtime communications framework around a networkservice. Through seamless integration of realtime communications (e.g.,realtime audio, video, chat, screen sharing, and file transfer) inpersistent virtual areas, these examples are able to enhance and improvecommunicants' experiences with a network service relative to traditionalbrowser based methods of collaborating on network service basedprojects. For example, instead of telephone based collaboration on ashared web browser view of a network service tool, examples describedherein enable distributed communicants to use multimodal communicationsto collaborate in a persistent shared context defined by a virtual areathat integrates a shared view of a network service based project with apersistent record of interactions that occur in the virtual area.

FIG. 3A shows an example of client network nodes 200 (A, B, C, and D)respectively interfacing with a network service 202 through respectivebrowser client applications 204 (only one browser client application isshown in FIG. 3A, the others being implied) over a network 206. Thenetwork service 202 typically is a service that provides a networkresource that can be shared by client network nodes. Examples of thenetwork service 202 include application services that deliver softwareapplications and other network-based tools as a service over the network206. In the illustrated example, the network service 202 is a webservice that delivers an application interface to the client networknodes 200 in the form of one or more web page documents 208. The browserclient applications 204 running on the client network nodes 200 renderthe web page documents 208 in a display area 212 of a browser interface210, which includes browser tools 214 for interacting with the networkservice 202. In the example shown in FIG. 3A, any realtimecommunications between the communicants operating the client networknodes 200 are performed without the benefits of a seamless integrationwith the shared view of the network service application interface and apersistent shared context.

FIG. 3B shows an example of the client network nodes 200 respectivelyinterfacing with the network service 202 and a virtual environmentcreation service 218 through respective virtual area based realtimecommunications client applications 216 (only one virtual area basedrealtime communications client application is shown in FIG. 1B, theothers being implied) over the network 206. The virtual area creationservice 218 typically is a service that supports realtime communicationsin a persistent virtual area 220. In the illustrated example, thenetwork service 202 delivers an application interface to the clientnetwork nodes 200 in the form of one or more web page documents 208, andeach of the virtual area based realtime communications clients runningon the client network nodes 200 renders the web page documents 208 in adisplay area 222 of a virtual area based realtime communications andnetwork service interface 224 that includes browser and collaborationtools 226 for interacting with the network service 202 and the virtualenvironment creation service 218. In the example shown in FIG. 1B, thecommunicants operating the client network nodes 200 have seamless accessto multimodal communications in a persistent shared context defined by avirtual area that integrates a shared view of a network service basedproject with a persistent record of interactions that occur in thevirtual area.

FIG. 4 shows an example of a method of associating a network servicewith virtual area based realtime communications that enablescommunicants to migrate from the non-realtime network serviceinteraction model shown in FIG. 3A to the realtime virtual area basednetwork service interaction model shown in FIG. 3B. In some examples,elements of the method of FIG. 4 are integrated with or otherwisecombined with elements of the virtual area creations methods describedabove.

In accordance with the method of FIG. 4, the virtual environmentcreation service 218 receives from a network service information forcreating a virtual area (FIG. 4, block 230). The virtual area creationprocess typically is initiated by a user of the network service (e.g.,an individual user, or an administrator or a project manager who managesa team of communicants who collaborate on a project through a toolprovided by the network service) through an integration interfaceprovided by the network service. The received information typicallyincludes information about the network service, information about theuser, and optionally information about one or more other communicantswho share the network service with the user.

The virtual environment creation service 218 provides an installationpackage for installing a virtual area based realtime communicationsclient application (FIG. 4, block 232). In some examples, the virtualenvironment creation service 218 maintains an association between theinformation received from the network service and the installationpackage so that the information can be used to customize the virtualarea based realtime communications client application that is installedon a client network node.

The virtual environment creation service 218 sends information thatdescribes properties of the virtual area including a property valueassociating the network service with the virtual area to the virtualarea based realtime communications client application that is installedon a client network node (FIG. 4, block 234). The information that issent to the virtual area based realtime communications clientapplication typically incorporates the network service into the virtualarea to provide a seamless integration of realtime communications andshared interactions with the network service.

FIG. 5 shows a flow diagram of an example of interactions between thenetwork service 202, the virtual area creation service 218, and a clientnetwork node 200.

In accordance with the flow diagram of FIG. 5, the network service 202provides an integration request interface to the client network node 200(FIG. 5, block 236). In some examples, the integration request interfaceis a web page that is associated with an integration component of thenetwork service 202. The web page provides a user-activatable interfacecontrol (e.g., a button) that can be activated by the user to initiate avirtual area creation process.

Using the integration request interface, the client network node 200initiates a virtual area creation process (FIG. 5, block 238). In someexamples, a web browser component of the client network node 200 rendersthe integration request interface on a display, receives input from theuser in connection with the user-activatable interface control, andtransmits an indication of the activation of the user-activatableinterface control to the network service 202.

Upon initiation of the virtual area creation process by the clientnetwork node 200, the network service 202 directs the user to thevirtual area creation service and sends account creation information tothe virtual area creation service 218 (FIG. 5, block 240).

In some examples, the user-activatable interface control in theintegration request interface is associated with a URL for a landing webpage provided by the virtual area creation service 218 for downloadingan installation package containing the virtual area based realtimecommunications application. The user-activatable interface controltypically also is associated with the integration component of thenetwork service 202, which gathers account creation information andnetwork service information relating to the network service 202 from oneor more databases that are maintained by the network service 202. Theintegration component sends to the virtual area creation service 218 astructured version of the account creation information (e.g., HTTP POSTQuery String, JSON, XML) that can be interpreted by the virtual areacreation service 218. In other examples, instead of having anintegration component, the network service 202 publishes an applicationprogramming interface (API) that allows the virtual area creationservice 218 to retrieve the communicant profile and network serviceinformation directly.

The account creation information typically includes virtual areainformation, communicant information, and network service information.

The virtual area information typically includes a virtual area type,name, and size. The virtual area type identifies a template for aspecific type of virtual area (e.g., a virtual auditorium, a virtualsupport center, a virtual center of excellence, a virtual networkoperations center, and a virtual area that models a specific workflowprocess). Examples of different types of virtual areas are described inU.S. Provisional Patent Application No. 61/603,024, filed Feb. 24, 2012.The virtual area size may be specified in a variety of different ways,including by specifying a respective number of zones of one or moredifferent types (e.g., individual offices, conference rooms, andauditorium), and a total number of communicant locations available foreach zone type (i.e., the number of simultaneous users that can bepresent in the zone).

The communicant information includes a list of the communicants who areto be designated as members of the virtual area and profile informationfor each of the members. Communicants may be designated as members ofthe virtual area as a whole. Communicants also may be designated asowners or co-owners of particular zones (e.g., offices or other rooms)in the virtual area, where ownership is associated with one or morecapabilities of the type described in U.S. Provisional PatentApplication No. 61/535,910, filed Sep. 16, 2011. In some examples, anowner of a room has a capability to control access to the owned zone(e.g., through control of a door object). The profile informationtypically includes the user's contact information (e.g., a communicationservice handle, such as an electronic mail address, and name). In someexamples, the network service 202 also obtains communicant profileinformation (e.g., a communication service handle and name) for othercommunicants that are associated with the user (e.g., communicants whoshare the same network service account with the user or are members ofthe same network service team as the user).

The network service information typically includes a URI for the networkservice (e.g., a URL for a homepage of the network service 202 or a URLfor a web page tied to a particular network service project associatedwith the user's account). The network service information also mayinclude a reference (e.g., a URI) to an iconographic representation ofthe network service (e.g., a logo or other icon associated with thenetwork service), an identifier (e.g., a partner key) that identifiesthe network service 202 to the virtual area creation service 218, adefinition for an object model to be used by the virtual area creationservice 218, and parameters of the landing web page provided by thevirtual area creation service 218. In some examples, the object modeldefinition describes where an object that integrates the network service202 into the virtual area will appear in the virtual area. The objectmodel definition may include a Type field identifies the network service(e.g., AgileZen) and a Location field identifier that identifies thelocation of the object (e.g., ApplicationId for the virtualarea+ZoneName for the zone in the virtual area+ObjectName for the objectin the zone) is used to seed an object in a zone of the virtual area. Insome examples, the landing page parameters include: a Partner ID thatidentifies which partner that will be associated with the virtual area;a Service Name that identifies the network service 202 to the uservisiting the landing page; a Beauty Image URL for the image thatpromotes the virtual environment creation service with the networkservice 202; a Logo URL for a logo identifying the network service 202;a Space Name for the resulting virtual area that will be created (e.g.,a pre-existing name for the user's team or project); and a Prop ID thatidentifies which prop should be placed in the resulting virtual area.

The virtual area creation service 218 stores the account creationinformation and provides a link for downloading a client applicationinstallation package (FIG. 5, block 242). The virtual area creationservice 218 extracts the account creation information from the requestreceived from the network service 202, generates a unique virtual areacustomization identifier (e.g., a universally unique identifier (UUID))for the extracted information, and stores the extracted information in adatabase in association with the virtual area customization identifiersuch that the information can be retrieved based on the virtual areacustomization identifier. The link for downloading the clientapplication installation package typically is provided on a web pagethat is cobranded with an identifier (e.g., a logo, brand name, ortrademark) of a provider of the virtual area creation service and anidentifier (e.g., a logo, brand name, or trademark) of a provider of thenetwork service. In some examples, the virtual area creation service 218associates the virtual area customization identifier with the clientapplication installation package (e.g., by embedding it in theinstallation package).

The client network node 200 downloads the installation package (FIG. 5,block 246). A browser component of the client network node 200 typicallydownloads the installation package associated with the link provided bythe virtual area creation service 218.

Using the installation package, the client network node 200 installs thevirtual area based realtime communications application (FIG. 5, block248). In this process, an installer component of the installationpackage installs the virtual area based realtime communicationsapplication, extracts the virtual area customization identifier from theinstallation package, and sends the virtual area customizationidentifier to the virtual area creation service 218.

The virtual area creation service 218 creates an account for the user(FIG. 5, block 250). In some examples, the virtual area creation service218 uses the virtual area customization identifier received from theclient network node 200 to retrieve the profile information for the userof the client network node 200 and network service information from theaccount creation information stored in the database, and sends theretrieved information to the client network node 200. The virtual areabased realtime communications client application displays on clientnetwork node 200 a dialog box that includes account creation fields thatare pre-populated with the information received from the virtual areacreation service 218. For example, the dialog box may include a username field, a user electronic mail address field, a network service URLfield, and a network service iconographic reference field that arepre-populated with values received from the virtual area creationservice 218. In some of these examples, the user may modify one or moreof the pre-populated account creation fields. The account creationdialog box includes a Submit button that allows the user to instruct theinstaller component of the installation package to submit an accountcreation request form that includes the dialog box field values to thevirtual area creation service 218. Based on receipt of the accountcreation request form, the virtual area creation service 218 creates anaccount for the user.

The virtual area creation service 218 builds a virtual area thatincludes an association between the network service 202 and the virtualarea (FIG. 5, block 252). In some examples, the virtual area creationservice 218 selects a specification of the virtual area, associates theuser with the virtual area (e.g., stores an identifier of the user in amember list for the virtual area), establishes a presence for the userin a particular position in the virtual area, and associates the networkservice 202 with the virtual area. In some of these examples, thevirtual area creation service 218 associates a URI of the networkservice 202 with the virtual area.

The virtual area creation service 218 sends a specification of thevirtual area to the client network node 200 (FIG. 5, block 254). Thevirtual area creation service 218 also typically sends the user presenceposition and the network service 202 association to the client networknode. In some examples, the virtual area creation service also sendscontact information for other communicants that are identified in theaccount creation information as being associated with the virtual area.

The client network node 200 displays the virtual area based realtimecommunications and network service interface for realtime communicationsand shared interactions with the network service in the virtual area(FIG. 5, block 256).

The virtual area based realtime communications application typicallyincludes functionality for inviting other communicants to the virtualarea. In some examples, the virtual area creation service 218 sendscontact information for other communicants that are associated with thevirtual area from the virtual area creation service 218 to the clientnetwork node 200. The installer component of the installation packagerunning on the client network node 200 displays an invitation dialog boxwith virtual area member fields (e.g., a member name field and a fieldfor a member's communication service handle, such as an electronic mailaddress) that are pre-populated with the contact information receivedfrom the virtual area creation service 218. In some of these examples,the user may modify one or more of the pre-populated virtual area memberfields. The invitation dialog box includes a Submit button that allowsthe user to instruct the installer component of the installation packageto submit invitations to the members identified in the invitation dialogbox using the invitation functionality of the virtual area basedrealtime communications application. Each invitation typically includesa link to the virtual area creation service that includes the virtualarea customization identifier. In some examples, the link in theinvitation directs a browser component of an invitee's client networknode to the cobranded web page provided by the virtual area creationservice 218 for downloading the client application installation packageto the invitee's client network node.

In one exemplary use case, the user who initiates the virtual areacreation process in connection with a particular network service (e.g.,a project management service) is a leader of a team that uses thenetwork service to provide joint access to one or more web documentsrelating to a particular project (e.g., a software development project).The network service 202 maintains a list of user names and contactinformation (e.g., email addresses) for the members of the team. Thenetwork service 202 includes this information in the account creationinformation that it sends to the virtual area creation service 218 (seeFIG. 5, block 240). The virtual area creation service 218 stores thisinformation in the database in association with the virtual areacustomization identifier so that it can be used by the team leader toinvite the other members of the team to the virtual area that is createdfor the team.

FIG. 6 shows an embodiment of an exemplary network communicationsenvironment 10 that includes a first client network node 12 (Client NodeA), a second client network node 14 (Client Network Node B), and avirtual area platform 18 that provides an example of the virtual areacreation service 218. The first client network node 12, the secondclient network node 14, and the virtual area platform 18 areinterconnected by an example 20 of the network 206. The network 20 mayinclude one or more of any of a local area network (LAN), a metropolitanarea network (MAN), and a wide area network (WAN) (e.g., the internet).The network 20 typically includes a number of different computingplatforms and transport facilities that support the transmission of awide variety of different media types (e.g., text, voice, audio, video,and other data) between network nodes.

The first client network node 12 includes a computer-readable medium 22(or “memory”), a processor 24, and input/output (I/O) hardware 26(including a display). The processor 24 executes at least onecommunications application 26 that is stored in the memory 22. Thesecond client network node 14 typically is configured in substantiallythe same general way as the first client network node 12, with acomputer-readable medium 30 storing at least one communicationsapplication 32, a processor 34, and input/output (I/O) hardware 36(including a display).

Each of the network nodes 12, 14 has a respective set of one or moresources and an exemplary set of one or more sinks. Exemplary sourcesinclude an audio source (e.g., an audio capture device, such as amicrophone), a video source (e.g., a video capture device, such as avideo camera), a chat source (e.g., a text capture device, such as akeyboard), a motion data source (e.g., a pointing device, such as acomputer mouse), and other sources (e.g., file sharing source or asource of a customized real-time data stream). Exemplary sinks includean audio sink (e.g., an audio rendering device, such as a speaker orheadphones), a video sink (e.g., a video rendering device, such as adisplay monitor), a chat sink (e.g., a text rendering device, such as adisplay monitor), a motion data sink (e.g., a movement rendering device,such as a display monitor), and other sinks (e.g., a printer forprinting shared files, a device for rendering real-time data streamsdifferent from those already described, or software that processesreal-time streams for analysis or customized display).

The virtual area platform 18 includes at least one server network node40 that provides a network infrastructure service environment 42 thatmanages sessions of the first and second client nodes 12, 14 in one ormore virtual areas 44 in accordance with respective virtual areaapplications 46. One or more of the virtual area applications 44typically are synchronous conferencing applications that support one ormore types of communications between the client nodes 12, 14 (e.g., textchat, audio conferencing, video conferencing, application sharing, andfile sharing). The network infrastructure service environment 42typically includes one or more network infrastructure services thatcooperate with the communications applications 28, 32 in the process ofestablishing and administering network connections between the clientnodes 12, 14 and other network nodes. Among the network infrastructureservices that are included in the example of the network infrastructureservice environment 42 are an account service, a security service, anarea service, a rendezvous service, an interaction service, and acapabilities engine. The area service administers a virtual area 44 bymanaging sessions of the first and second client nodes 12, 14 in thevirtual area 44 in accordance with the virtual area application 46.Examples of the virtual area platform 18 and the virtual areaapplications 46 are described in U.S. Provisional Patent Application No.61/563,088, filed Nov. 23, 2011. Examples of an account service, asecurity service, an area service, a rendezvous service, and aninteraction service are described in U.S. patent application Ser. No.12/630,973, filed Dec. 4, 2009. Examples of a capabilities engine aredescribed in U.S. Provisional Patent Application No. 61/535,910, filedSep. 16, 2011.

The network infrastructure service environment 42 maintains arelationship database 47 that contains the records 48 of interactionsbetween communicants and social network profiles 50 that are associatedwith respective communicants. Each interaction record describes thecontext of an interaction between a pair of communicants. For example,in some examples, an interaction record contains one or more of anidentifier for each of the communicants, an identifier for the place ofinteraction (e.g., a virtual area instance), a description of thehierarchy of the interaction place (e.g., a description of how theinteraction room relates to a larger area), start and end times of theinteraction, and a list of all files and other data streams that areshared or recorded during the interaction. In some examples, eachinteraction is tracked independently such that, for a given pair ofcommunicants, there is a list of relationship event records, each ofwhich records a single respective interaction (e.g., sent a chatmessage, streamed audio for 93 seconds, shared file X, etc.). Thus, foreach realtime interaction, the network infrastructure serviceenvironment 42 tracks when it occurred, where it occurred, and whathappened during the interaction in terms of communicants involved (e.g.,entering and exiting), objects that are activated/deactivated, and thefiles that were shared. Each social network profile 50 typicallyincludes: identity characteristics (e.g., name, age, gender, andgeographic location information such as postal mailing address) thatdescribe a respective communicant or a persona that is assumed by thecommunicant; explicit relationship information that is declared by thecommunicant; and relationship information that is inferred from thecommunicant's interactions in the network communication environment 10.

The communications applications 26, 32, the area applications 46, andthe network infrastructure service environment 42 together provide aplatform (referred to herein as “the platform”) that administers therealtime connections with network nodes in a communication context thatis defined by an instance of a virtual area subject to a set ofconstraints 43 that control access to the virtual area instance.

The communications applications 26, 32 present respective views of thevirtual areas 44 in accordance with data received from the networkinfrastructure service environment 42 and provide respective interfacesfor receiving commands from the communicants and providing a spatialinterface that enhances the realtime communications between thecommunicants. The communicants typically are represented in the virtualareas 44 by respective avatars (e.g., sprites), which typically moveabout the virtual areas 44 in response to commands that are input by thecommunicants at their respective network nodes. In some examples, thecommunications applications 26, 32 establish realtime data streamconnections between the first and second client network nodes 12, 14 andother network nodes sharing the virtual area 44 based on the positionsof the communicants' avatars in the virtual areas 44 as described inU.S. Pat. Nos. 7,769,806 and 7,844,724.

Among the software components executing on the client network nodes 12,14 are a user interface component and a browser component. The browsercomponent provides a set of web browsing functions, including browserfunctions, document viewing functions, and data downloading functions.The user interface component generates a graphical user interface thatinterfaces the user to the realtime communications and network browsingfunctionalities of the browser component. The browser component may beintegrated into the communications applications 26, 32 or it may beimplemented by a separate browser component (e.g., a plug-in) thatexposes an API through which the communications applications 26, 32 maycall methods that are available from the browser component, includingbrowsing methods, document viewing methods, and data downloadingmethods.

The network connections between network nodes may be arranged in avariety of different stream handling topologies, including apeer-to-peer architecture, a server-mediated architecture, and hybridarchitectures that combine aspects of peer-to-peer and server-mediatedarchitectures.

In some embodiments, the server network node 40 remotely manages clientcommunication sessions and remotely configures audio and graphicrendering engines on the client network nodes 12, 14, as well asswitching of data streams by sending instructions (also referred to asdefinitions) from the remotely hosted area applications 46 to the clientnetwork nodes in accordance with the stream transport protocol describedin U.S. patent application Ser. No. 12/825,512, filed Jun. 29, 2010, theentirety of which is incorporated herein by reference. In some of theseembodiments, the server node(s) 40 send to each of the client nodes 12,14 provisioning messages that configure the client nodes 12, 14 tointerconnect respective data streams between active ones of theircomplementary sources and sinks in accordance with switching rulesspecified in the server applications 46.

The platform tracks communicants' realtime availabilities and activitiesacross the different communication contexts that are defined by the areaapplications 46. This information is presented to the communicants inthe form of realtime visualizations that enable the communicants to makemore informed network interaction decisions (e.g., when to interact witha contact) and encourages the communicants to initiate interactions withother communicants and to join contexts (e.g., an ongoing conversationbetween communicants) of which the communicants otherwise would not havebeen aware. In some embodiments, the realtime visualization includesvisual cues as to the presence and activities of the communicants in thecontexts of the server applications. The presentation of these visualcues typically depends on one or more of governance rules associatedwith the virtual areas 44, administrative policies, and user preferences(including preferences regarding the exportation of the user's presenceand the connection of the user to areas and other communicants), whichmay define tiered relationship based predicates that control access topresence information and/or resources on a zone-by-zone basis.

A virtual area 44 may correspond to an abstract (non-geometric) virtualarea that is defined with respect to abstract coordinates, or a visualvirtual area that is defined with respect to one-, two- orthree-dimensional geometric coordinates. Abstract virtual areas may ormay not be associated with respective visualizations, whereas visualvirtual areas are associated with respective visualizations.

In some of the examples that are described herein, the virtual areas arevisual virtual areas of the type disclosed in U.S. Pat. Nos. 7,769,806and 7,844,724. These visual virtual areas include physical geometry andcollision geometry. The physical geometry describes the shape of thevirtual area. The physical geometry typically is formed from surfaces oftriangles, quadrilaterals, or polygons. Colors and textures are mappedonto the physical geometry to create a more realistic appearance for thevirtual area. Lighting effects may be painted onto the visual geometryand the texture, color, or intensity near the lighting effects may bemodified. The collision geometry describes invisible surfaces thatdetermine the ways in which objects can move in the virtual area. Thecollision geometry may coincide with the visual geometry, correspond toa simpler approximation of the visual geometry, or relate toapplication-specific requirements of a virtual area designer.

Some examples of the virtual area platform enable software applicationdesigners to define the semantics of position in an abstract virtualarea (e.g., a software application or a computer data file). Throughassociations with respective connection rules, these positiondefinitions can be used, for example, to drive connections to virtualareas, entries into virtual areas, connections to communicants and othersources or sinks of realtime data streams, and determinations ofpresence data relating to communicants, network resources, and networkservices. Additional details regarding systems and methods of definingthe semantics of position in abstract virtual areas are described inU.S. application Ser. No. 12/631,008, which was filed on Dec. 4, 2009.

A virtual area typically includes one or more zones. A zone may be arendered spatial extent, a set of rules applied to a spatial extent, orboth. Zones may be arranged hierarchically in a virtual area, with anoutermost zone (referred to herein as the “Global Governance Zone”)enclosing all other zones in the virtual area. Within the GlobalGovernance Zone, there can be location zones (e.g., rooms of a virtualarea) or smaller governance zones that enclose a group of location zonesand provide regions of governance on the map. A zone definitiontypically also includes one or more channel definitions that describehow to create respective content specific communications channels in thezone and specify the information about the channel that is published toa client network node that becomes present in the zone. A channel isalways uniquely defined point-to-point and is unique to a session and avirtual area application.

Examples of the types of rules that may be associated with a zoneinclude switching rules, governance rules, and permission rules.

Switching rules govern realtime stream connections between network nodesthat are linked to the virtual area (e.g., network nodes that areassociated with objects, such as avatars, in the virtual area). Theswitching rules typically include a description of conditions forconnecting sources and sinks of realtime data streams in terms ofpositions in the virtual area. Each switching rule typically includesattributes that define the realtime data stream type to which the ruleapplies and the location or locations in the virtual area where the ruleapplies. In some examples, each of the rules optionally may include oneor more attributes that specify a required role of the source, arequired role of the sink, a priority level of the stream, and arequested data routing topology. In some examples, if there are noexplicit switching rules defined for a particular part of the virtualarea, one or more implicit or default switching rules may apply to thatpart of the virtual area. One exemplary default switching rule is a rulethat connects every source to every compatible sink within an area,subject to policy rules. Policy rules may apply globally to allconnections between the area clients or only to respective connectionswith individual area clients. An example of a policy rule is a proximitypolicy rule that only allows connections of sources with compatiblesinks that are associated with respective objects that are within aprescribed distance (or radius) of each other in the virtual area. Thenetwork connections between network nodes may be arranged in a varietyof different data routing topologies, including a peer-to-peer topology,a mediated topology (i.e., a topology in which connections betweennetwork nodes are mediated by another network node, such as a servernetwork node, a client network node, or a network switch), and hybridarchitectures that combine aspects of peer-to-peer and mediatedarchitectures. In some examples, the switching rules dictate how localconnection processes executing on each of the network nodes establishescommunications with the other network nodes based on the locations ofthe associated objects in the zones of the virtual area. A switchingrule also may define a direct connection between network nodes or anindirect connection through an intermediate network node.

Governance rules control who has access to resources (e.g., the virtualarea itself, regions with the virtual area, and objects within thevirtual area), who has access to data (e.g., data streams and othercontent) that is associated with the virtual area, what is the scope ofthat access to the data associated the virtual area (e.g., what can auser do with the data), and what are the follow-on consequences ofaccessing that data (e.g., record keeping, such as audit logs, andpayment requirements). In some examples, an entire virtual area or azone of the virtual area is associated with a “governance mesh” thatenables a software application developer to associate governance ruleswith a virtual area or a zone of a virtual area. This avoids the needfor the creation of individual permissions for every file in a virtualarea and avoids the need to deal with the complexity that potentiallycould arise when there is a need to treat the same document differentlydepending on the context.

A permission rule defines a respective capability requirement (e.g., fora respective action, behavior, or state) in terms of one or morecapabilities, attributes, and settings, which may be persistent ortransient. Examples of permission rules include: a rule that conditionsa communicant's ability to enter a target zone on the communicant havinga CanEnterZone capability for the target zone; a rule that conditionsthe ability of a grantee communicant to open a target door of a targetroom on the grantee communicant having a CanOpenDoor capability for thetarget room; and a rule that conditions the transmission of a messagedescribing the state of a particular communicant's avatar in a zone to arecipient having a CanSeeState capability for the particular communicantin the zone. A capability provides permission for a client to performsome action within the application. For example, a client may be grantedthe capability “CanEnterZone” for a specific zone within a virtual areathat has been defined with that capability requirement. The client thathas the capability can enter the zone, whereas a client without thecapability would have their RDS state change rejected when they tried toenter the zone. Examples of capabilities systems for administeringpermission rules are described in U.S. Provisional Patent ApplicationNo. 61/535,910, filed Sep. 16, 2011.

As explained above, the zones of a virtual area can be associated withrespective switching rules, each of which instructs the area service toconnect sources of a respective data stream type that are associatedwith a designated source zone with sinks of the respective realtime datastream type that are associated with a designated sink zone. Networknodes can establish respective presences in the zones of a virtual area.In some examples, network nodes associated with respective objects(e.g., avatars representing the communicants operating the networknodes) that can be moved to different locations in the virtual area, andthe network nodes are present in the zones in which the associatedobjects are located. The area service administers data streamconnections between the network nodes based on the switching rules, therespective sources and sinks associated with the network nodes, and therespective zones of the virtual area in which the objects are located.

FIG. 7A shows an example of a graphical user interface 152 that presentsa two-dimensional view of a visual virtual art gallery area 154.Communicants are represented in the virtual area 154 by respectiveavatars 156, 158, 160, each of which may have a respective role (e.g., acurator, an artist, and a visitor) in the virtual area 166. The virtualarea 154 includes zones 162, 164, 166, 168, 170, 172. (During a typicalcommunication session, the dashed lines demarcating the zones 162-172 inFIG. 7A are not visible to the communicants although there may be visualcues associated with such zone boundaries.) In some examples, each ofthe zones 162-172 has a respective zone boundary that is associated witha respective <zone_mesh> tag that has a number of attributes (e.g.<zone>, <stream> and <sink> tags) in accordance with the COLLADA StreamsReference specification described in U.S. Pat. Nos. 7,769,806 and7,844,724. In other examples, zones are associated with one or morerespective control channels on which data streams of respective datatypes are sourced from the zones and/or control channels that arepublished in the zones and can be subscribed to by network nodes in thezones.

FIG. 7B shows a plan view of the virtual art gallery area 154 at a timewhen it is populated with four avatars W, X, Y, and, Z. The avatars Wand X are positioned in the zone 162 and the avatars Y and Z arepositioned in the zone 170. For the purpose of this illustrativeexample:

-   -   each of the avatars W-Z is associated with voice, video, and        chat source types and sink types;    -   the switching rules for zone 162 specify that        -   each voice source that is associated with an avatar within            the zone 162 is to be connected to every voice sink within            the zone 162,        -   each video source that is associated with an avatar within            the zone 162 is to be connected to every video sink within            the zone 162, and        -   each chat source that is associated with an avatar within            the zone 162 is to be connected to every chat sink within            the zone 162;    -   the switching rules for zone 170 specifies only that that each        voice source that is associated with an avatar within the zone        170 is to be connected to every voice sink within the zone 170;        and    -   the server node executes a message handling service for the        virtual area 154 that implements, on top of the zone switching        rules, a proximity policy rule that only allows connections of        sources with compatible sinks that are associated with        respective objects that are within a prescribed distance (or        radius), r_(P), of each other in the virtual area.

In this example, the switching rules and the proximity policy ruleprovide respective switching conditions that determine how theconnections between the avatars W, X, Y, and Z are established.

In operation, the message handling service for the virtual area 154sends instructions for the area client node that is associated withavatar W to connect to the real-time voice, video, and chat streams thatare sourced from the area client node that is associated with avatar Xwhenever avatar X is positioned within a proximity zone 173, whichdefined by the prescribed distance r_(P), around avatar W. Likewise, themessage handling service sends instructions for the area client nodethat is associated with avatar X to connect to the real-time voice,video, and chat streams that are sourced from the area client node thatis associated with avatar W whenever avatar W is positioned within theprescribed distance r_(P) of avatar X. Since avatar X currently isoutside the proximity zone 173 of avatar A, and vice versa, the nodesassociated with avatars W and X are not connected to each other in thecurrent state shown in FIG. 7B.

Since the zone 170 only allows voice connections, the message handlingservice sends instructions for the area client node that is associatedwith avatar Y to connect to only the real-time voice stream that issourced from the area client node that is associated with avatar Z(assuming the proximity condition specified in the proximity policy ruleis satisfied). Similarly, the message handling service sendsinstructions for the area client node that is associated with avatar Zto connect to only the real-time voice stream that is sourced from thearea client node that is associated with avatar Y (assuming theproximity condition specified in the proximity policy rule issatisfied).

Since the switching rules for zones 162 and 170 do not allow connectionsbetween zones 162 and 170, the sources and sinks that are associatedwith avatars W and X are not connected to any of the sources and sinksthat are associated with avatars Y and Z, even if the proximitycondition specified in the proximity policy rule is satisfied.

In some examples, a non-rendered governance zone typically encompasses acollection of one or more rendered location zones. One or more controlchannels are defined within a governance zone. A governance zonefunctions as a “sink” for data sent on the associated control channel,whereas a location zone that specifies the same control channelfunctions as the “source” of the control channel data. A user who ispresent in any one of the location zones within a governance zone isalso present within the governance zone.

A control channel is a collection of channels that share a commondefinition that is managed by exactly one area/zone manager, which is acomponent of the area service (examples of area/zone managers aredescribed in U.S. Provisional Patent Application No. 61/563,088, filedNov. 23, 2011). A control channel is published by its corresponding zonemanager when a communicant enters a zone that the zone manager hasresponsibility for. For example, a chat control channel describes thechat channels that exist (i.e., the channels that contain the chatdata). When a communicant enters a room, the chat control channelpublishes the chat channels that are available for the room, thecommunicant's client communicants application subscribed to a particularchat channel and the chat history was sent down to the clientcommunications application on that channel. A single area/zone managercan manage multiple control channels. When a message is passed from amessage handler to a zone manager, the message handler sends the zonemanager the ID of the control channel on which the message came on sothat the zone manager operate in the correct context defined by thecontrol channel ID.

FIG. 8 shows an example of a realtime data stream (RDS) zone map thatdefines how RDS streams are sourced and sunk in a virtual area. In someexamples, the RDS streams carry RDS data indicating activity on one ormore communicant communications channels (e.g., communicant audiochannels, communicant chat channels); the RDS data is used to showvisual cues of indicating current communicant activities in a virtualarea. The virtual area specification may include analogous zone maps forother channels that are defined for the virtual area. Some controlchannels, such as the session control channel and the area definitionchannel, only have a single instance. The virtual area includes sevenlocation zones: Conference Room 1, Conference Room 2, Conference Room 3,DVW Office, PJB Office, Strange Room 1, and Strange Room 2. The virtualarea also includes five governance zones: a global area wide zone 174, azone 176 containing all three conference rooms, zones 178, 180, 182,184, 186 for each office (which coincide with the location zones), andzones 188, 190 for Strange Room 1 and Strange Room 2.

Alex is present in Conference Room 1, GZ1, GZ2 and DVW Office (GZ3), Bobis present in Conference Room 1, GZ1 and GZ2, Joe is present inConference Room 2, GZ1 and GZ2, Tom is present in Conference Room 2,GZ1, GZ2 and PJB Office/GZ4, David is present in DVW Office/GZ3 and GZ1,Paul is present in PJB Office/GZ4 and GZ1, Matt is present in StrangeRoom 1/GZ5 and GZ1, and Chris is present in Strange Room 2 and GZ1.

There are five control channels for RDS, one published by each zoneexcept zone 190, which does not publish any RDS data: RDSChan1 ispublished by zone 174; RdsChan2 is published by zone 176; RdsChan3 ispublished by zone 184; RdsChan4 is published by zone 186; and RdsChan5is published by zone 188. RDS activity in a zone is sent out on all RDSzone manager control channels for that zone and delivered to all userspresent in the governance zones that publish those control channels.

Activity in any of conference room 1 or conference room 2 is publishedon RdsChan1, which is published by an area/zone manager for governancezone 174. Since every user in the area is in governance zone 174, allusers in the area are subscribed to RdsChan1 and see the RDS activity inConference Rooms 1 and 2 (governance zones 178, 180). An area/zonemanager for governance zone 182 publishes activity in Conference Room 3(governance zone 182) on RdsChan2. In this case, only Alex, Bob, Joe andTom are in governance zone 176, so only they are subscribed to thechannel and see Tom's Activity in Conference Room 3. Since RdsChan1 isnot a control channel for Conference Room 3, activity in Conference Room3 is not broadcasted on that channel. Activity in the DVW Office is sentout on RdsChan3, which is published by governance zone 184 and thereforeis only visible to David and Alex since they are the only ones presentin that zone. Likewise, activity in the PJB Office is sent out onRdsChan4, which is published by governance zone 186 and therefore isonly visible to Paul and Tom since they are the only ones present inthat zone. Activity in Strange Room 1 is not visible anywhere, not evenin Strange Room 1 since it doesn't specify an RDS Control Channel.Activity in Strange Room 2 is sent out on RdsChan5, which is publishedby governance zone 188 and therefore is broadcast to Matt in StrangeRoom 1. Thus, no one can see Matt's activity in Strange Room 1 (not evenMatt) and only Matt can see Chris's activity in Strange Zone 2.

As explained above, the zones of a virtual area can be associated withrespective switching rules, each of which instructs the area service toconnect sources of a respective data stream type that are associatedwith a designated source zone with sinks of the respective realtime datastream type that are associated with a designated sink zone. Networknodes can establish respective presences in the zones of a virtual area.In some examples, network nodes associated with respective objects(e.g., avatars representing the communicants operating the networknodes) that can be moved to different locations in the virtual area, andthe network nodes are present in the zones in which the associatedobjects are located. The area service administers data streamconnections between the network nodes based on the switching rules, therespective sources and sinks associated with the network nodes, and therespective zones of the virtual area in which the objects are located.

In some examples, a virtual area includes multiple zones each of whichsupports an independent communication session between network nodes inthe zone. For example, a virtual area may include zones in which audio,video, and text chat channel connections are established only betweenthe sources and sinks of network nodes that are in the same zone. Inthese examples, the spatial visualizations of the virtual area that arepresented on the client network nodes show, in a single view, all theindependent communications that are occurring in the zones of thevirtual area. This allows a user to see multiple simultaneousindependent communication interactions in a single view and therebyquickly learn who is meeting with whom and the contexts of thosemeetings (as defined by the zones in which the meetings are occurring).

FIG. 9 shows an exemplary graphical user interface 70 that is generatedby an example of the communications application 26 in a window 59 on adisplay of the client network node from which a user of the clientapplication (“Art” in this example) is operating. The graphical userinterface 70 includes a people panel 65, a viewer panel 66, a peopleinteraction toolbar 67, an audio interaction toolbar 68, and a set ofpanel view controls 69.

The people interaction toolbar 67 includes a Chat button 98 and anInvite button 102. Selection of the Chat button 98 opens a chat panel140 (see FIG. 11) that enables Art to initiate a chat with othercommunicants who are present in the area application where Art ispresent (i.e., Zone 1 in the illustrated example). Selection of theInvite button 102 opens an Invite window that enables Art to invite oneor more communicants to a selected virtual area location (e.g., an areaapplication or zone within that area application). Additional detailsregarding embodiments of the methods and functions invoked by the Chatbutton 98 and the Invite button 102 are described in U.S. patentapplication Ser. No. 12/354,709, filed Jan. 15, 2009, and U.S.Provisional Patent Application No. 61/373,914, filed Aug. 16, 2010.

The audio interaction toolbar 68 includes a headphone control 84 thatenables Art to toggle on and off the local speakers of the clientnetwork node, and a microphone control 86 that enables Art to toggle onand off the local microphone of the client network node.

The panel view controls 69 include a people panel button 71 for openingand closing the people panel 65, a chat panel button 73 for opening andclosing the chat panel 140 (see FIG. 11), and a viewer panel button 75for opening and closing the viewer panel 66.

The people panel 65 depicts the realtime availabilities and activitiesof some or all of Art's contacts across different communicationcontexts. In the example shown in FIG. 9, the people panel 65 showsArt's communicants segmented into two zone groups 72, 74 and a contactsgroup 76. The zone groups 72, 74 correspond to respective zones of aparticular one of the area applications 44 of which Art is a member andis present. The contacts group 76 contains all or a selected portion ofArt's contacts that are not represented in any of the zone groups. Thefirst zone group 72 of communicants is contained within a section 78(labeled with a header bar entitled “Zone 1”) that identifies all thecommunicants who are present in Zone 1 of the particular virtual areaapplication. The second virtual area group 74 of communicants iscontained within a section 80 (labeled with a header bar entitled “Zone2”) that identifies all the communicants who are present in Zone 2 ofthe particular virtual area application. The contacts group 76 ofcommunicants is contained within a section 82 (labeled with a header barentitled “Contacts”) that identifies all of Art's contacts who are notpresent in any of the first and second zone groups 72, 74.

In the example shown in FIG. 9, the sections 78, 80 of the people panelcontain the graphical representations (avatars) of the communicants(including at least one of Art or Art's contacts) who currently arepresent in the respective zones of the particular virtual areaapplication 46, and the contacts section 82 contains graphicalrepresentations (avatars) of all of the remaining ones of Art's contactsthat are not present in any of Zone 1 and Zone 2. In the illustratedexample: Art and Beth are present Zone 1; Carl, Dan, and Ed are presentin Zone 2; and Fran and Garth are contacts of Art who are not present inthe virtual area containing Zone 1 and Zone 2

Each communicant is represented graphically by a respective circularsprite that is labeled with a respective user name of the communicant(i.e., “Art,” “Beth,” “Carl,” “Dan,” “Ed,” “Fran,” and “Garth”). Eachsprite also may be associated with a respective status line thatincludes additional information about the communicant. In someembodiments, each status line can include one or more of the followinginformation: location of presence (e.g., a server application or a zoneof that sever application); availability (e.g., busy, idle); a statusmessage (e.g., “Out of the office next Wednesday”); and the name of theclient node from which the communicant is operating (e.g., “workstation1” or “mobile phone”). In some embodiments, the ordering of the spatialpositions (e.g., from top to bottom) of the communicant avatars in eachof the sections 78, 80, 82 is alphabetical by user name. In otherembodiments, the spatial positions of the communicant avatars in each ofthe server application sections 78, 80 are ordered in accordance withthe temporal ordering of the communicants in terms of the times when thecommunicants established their respective presences with the serverapplications. The spatial positions of the communicant avatars in thecontacts section 82 may be sorted alphabetically by user name, accordingto frequency of contact, according to recentness of contact, oraccording to other sorting or filtering criteria.

The activities of the communicants in the contexts of the areaapplications 44 may be inferred from the activities on communicationchannels over which the respective communicants are configured tocommunicate. The activities on the communication channels are shown inthe graphical user interface 70 by visual cues that are depicted inassociation with the graphical representations of the communicants inthe sections 78, 80, 82. For example, the “on” or “off” state of acommunicant's local speaker channel is depicted by the presence orabsence of a headphones graphic 90 on the communicant's sprite. When thespeakers of the communicant who is represented by the sprite are on, theheadphones graphic 90 is present (see sprites Art, Carl, and Dan) and,when the communicant's speakers are off, the headphones graphic 90 isabsent (see sprites Beth and Ed). The “on” or “off” state of thecommunicant's microphone is depicted by the presence or absence of amicrophone graphic 92 on the communicant's sprite. When thecommunicant's microphone is on, the microphone graphic 92 is present(see sprite Dan); and, when the communicant's microphone is off, themicrophone graphic 92 is absent (see sprites Art, Beth, Carl, and Ed).The headphones graphic 90 and the microphone graphic 92 provide visualcues of the activity states of the communicant's sound playback andmicrophone devices. In addition, the current activity state of acommunicant's microphone channel is indicated by a dynamic visualizationthat lightens and darkens the communicant's avatar in realtime toreflect the presence or absence of audio data on the microphone channel.Thus, whether or not their local speakers are turned on, communicantscan determine when another communicant is speaking by the “blinking” ofthe coloration of that communicant's avatar. The activity state of acommunicant's text chat channel is depicted by the presence or absenceof the hand graphic 94 adjacent the communicant's sprite (see spriteBeth). Thus, when a communicant is transmitting text chat data toanother network node the hand graphic 94 is present, and when acommunicant is not transmitting text chat data the hand graphic 94 isnot present. In some embodiments, text chat data is transmitted onlywhen keyboard keys are depressed, in which case the visualization of thecommunicant's text channel appears as a flashing on and off of the handgraphic 94.

In the example shown in FIG. 9, members of an area application are ableto receive the visual cues of the communicant activities occurring inthe contexts defined by the zones of that area application whether ornot the members are present in the zone in which the communicantactivities are occurring. Thus, the graphical user interface 70 that ispresented to Art shows visual cues indicating the communication channelactivities of the communicants present in Zone 1 (where Art is present)and the communication channel activities of the communicants present inZone 2 (where Art is not present).

Additional details regarding embodiments of the people panel 65 aredescribed in U.S. Provisional Patent Application No. 61/373,914, filedAug. 16, 2010, and U.S. patent application Ser. No. 12/354,709, filedJan. 15, 2009.

The viewer panel 66 includes a navigation area 110 and a display area112.

The navigation area 110 includes forward and back buttons 114, alocation bar 116, a Go button 118, and a reload button 120. The forwardand back buttons 114 enable a user to traverse a navigation stack ofuniform resource identifier (URI) addresses (e.g., a linked list ofpreviously visited URLs). The location bar 116 allows a user to specifya URI address of a network resource, and the Go button 118 invokes oneor more browser functions on the client network node to navigate to thespecified URI address and render the network resource at the specifiedURI address in the display area 112. The reload button 120 invokes oneor more browser functions on the client network node to reload thegraphic representation of the network resource currently displayed inthe display area 112.

The display area 112 contains the rendered depictions of networkresources located at the URI address specified in the navigation area110. In the example shown in FIG. 9, the viewer panel 66 is in thebrowser view mode and shows a rendered view of the network resource (aweb page in this example) that is located at the URLhttps://www.sococo.com/home.php, as indicated in the location bar 116.In the illustrated example, the display area 110 shows a web page thatincludes a header section 122, a top navigation bar 124, a sidenavigation bar 126, a contents section 128, a notices section 130, and anavigation links section 132.

In addition to the control and panel elements of the graphical userinterface 70 (e.g., the people panel 65, the viewer panel 66, the peopleinteraction toolbar 67, the audio interaction toolbar 68, and the panelview controls 71, 73, 75), the graphical user interface 70 includes aShare button 375 and a set 373 of Viewer Panel control buttons,including a Map button 376, a Browse button 378, and four View Screenbuttons 380-386. The Share button 375 initiates a screen share of thecontents of the display area 112 of the viewer panel 66 in connectionwith a view screen object in a virtual area. These contents include, forexample, renderings of any information that is received by the browsercomponent in connection with the network resource identified in thelocation bar 116, and a document or application that is being shared bythe user in connection with a view screen object in a virtual area. TheMap button 376 sets the view presented in the viewer panel 66 to a mapview of the virtual area. The Browse button 378 sets the view presentedin the viewer panel 66 to a browser view. Each of the four View Screenbuttons 380-386 sets the viewer panel 66 to display the content beingshared in connection with a corresponding one of the view screens in thevirtual area.

FIG. 10 shows an example of the graphical user interface 70 in the Mapview mode presenting in the viewer panel 66 a rendered view of a zone(i.e., Zone 1) of the virtual area SococoHQ that is located at thelocation SococoHQ/Zone1, as indicated in the location bar 110.

Each of the communicants who is present in the virtual area isrepresented graphically by a respective avatar that corresponds to thecommunicant's avatar that is shown in the people panel 65. The virtualarea is represented graphically by a two-dimensional top view of arectangular space. In some examples, the communicants' spritesautomatically are positioned in predetermined locations (or “seats”) inthe virtual area when the communicants initially enter the virtual area.

The virtual area includes four view screen objects 388, 390, 392, 394and a table object 396. Communicants interact with the objects byselecting them with an input device (e.g., by single-clicking on theobjects with a computer mouse, touch pad, touch screen, or the like).

The view screen objects 388-394 are associated with application sharingfunctionality of the platform that enables communicants to shareapplications operating on their respective client network nodes. Theapplication sharing functionality is invoked by activating a view screenobject (e.g., by single-clicking the view screen object with an inputdevice). In some embodiments, the platform provides visual cues thatindicate whether or not a communicant is sharing an application over anapplication sharing channel. In response to a communicant's selection ofthe view screen object, the communicant's sprite automatically is movedto a position in the graphical representation of the virtual area thatis adjacent the view screen object. The position of a communicant'ssprite adjacent the view screen object indicates that the communicantcurrently is sharing or is about to share an application with the othercommunicants in the virtual area. In addition, the avatar of eachcommunicant who is viewing a shared application (including the sharingcommunicant) is depicted with a pair of “eyes” to indicate that therepresented communicants are viewing the content being shared inconnection with the view screen objects (see, e.g., the avatars of Bethand Dan in FIG. 10). The graphical depiction of view screen object ischanged depending on whether or not an active application sharingsession is occurring. For example, the depicted color of the view screenobject may change from a brighter color during an active applicationsharing session to a darker color when there is no application sharingtaking place. Examples of the application sharing process are describedin connection with FIGS. 26-28 of U.S. patent application Ser. No.12/354,709, filed Jan. 15, 2009, and in U.S. patent application Ser. No.12/418,270, filed Apr. 3, 2009.

Any of the viewscreen props 388-394 may be associated with respectiveuniform resource identifiers (URIs) of network resources (e.g., networkservices) to enable communicants to interact with and share informationassociated with the network resources in connection with the viewscreenobjects as described in U.S. patent application Ser. No. 13/399,737,filed Feb. 17, 2012. In the example shown in FIG. 10, the viewscreenobject 390 is associated with the URL of a network service and aniconographic representation of the network service (represented by thelabel “Web Service Icon”) is displayed in association with theviewscreen object 390.

The table object 396 is associated with file sharing functionality ofthe platform that enables communicants to upload computer data files toserver storage in association with the virtual area and to download datafiles that are associated with the virtual area from the server storageto the respective client network nodes. In example shown in FIG. 10,there are two document objects 398, 400 that are associated with thetable object 396. The document objects 398, 400 are linked to respectivedocuments that are have been shared in the virtual area and stored inserver storage. Any of the document objects 398, 400 may be selected bya communicant (e.g., by double-clicking the document object 190 with aninput device, such as a computer mouse) to initiate downloading of theassociated document to the communicant's client network node. Additionaldetails regarding the structure, function, and operation of the tableprop 396 may be obtained from U.S. patent application Ser. No.12/354,709, filed Jan. 15, 2009.

In the Map view mode, the navigational controls of the graphical userinterface 70 allow the user to traverse a path through the virtualenvironment in accordance with a navigational model that is tied to theunderlying spatial hierarchy of virtual area locations and objectswithin the locations. The network infrastructure service environmentrecords the path traversed by the user. In some embodiments, the networkinfrastructure service environment records a history that includes atemporally ordered list of views of the virtual area locations that arepresented to the user as the user navigates through the virtual area.Each view typically corresponds to a view of a respective renderablezone of the virtual area. In these embodiments, the navigation controlsenable the user to move to selected ones of the zones in the history.The navigation controls also include a graphical representation of adepth path that shows the location in the spatial hierarchy thatcorresponds to the user's current view of the virtual area. In someembodiments, the graphical representation of the depth path includes arespective user-selectable link to a respective view of each of thepreceding levels in the spatial hierarchical model of the virtual areaabove the current view. The back button 369 corresponds to a backwardcontrol that enables the user to incrementally move backward topreceding ones of the zones in the history of the zones that weretraversed by the user. The forward button 371 corresponds to a forwardcontrol that enables the user to incrementally move forward tosuccessive ones of the zones in the history of the zones that weretraversed by the user. Some examples additionally include a placemarksbutton that activates a placemarking control for storing links to zonesand a placemark navigation control for viewing a list of links topreviously placemarked zones. In response to user selection of theplacemarking control, a placemark is created by storing an image of thelocation shown in the current view in association with a hyperlink tothe corresponding location in the virtual area. In response to a userselection of the placemark navigation control, a placemarks window ispresented to the user. The placemarks window includes livevisualizations (showing, e.g., where communicants are located and visualcues of their realtime activities) of all locations that have beenplacemarked by the user. Each of the images in the placemarks window isassociated with a respective user-selectable hyperlink. In response touser selection of one of the hyperlinks in the placemarks window, a viewof the virtual area corresponding to the location associated with theselected hyperlink is automatically displayed in the browsing area ofthe graphical user interface 70. Some examples include home buttoncorresponds to a control that returns the user to a view of a designated“home” location in the virtual environment. Additional details regardingthe structure, function, and operation of examples of the navigationcontrols are described in U.S. patent application Ser. No. 12/354,709,filed Jan. 15, 2009.

FIG. 11 shows an example of the graphical user interface 70 when thepeople panel 65, a chat panel 140, and the viewer panel 66 are open.

Activating the chat panel button 73 or the chat button 98 opens the chatpanel 140. When the chat panel button 73 is activated, the chat panel140 opens to show a chat interface for a persistent virtual chat areafor interactions occurring in connection with a respective virtual area.In the example shown in FIG. 11, Art activated the chat panel button 73at the time he was present in Zone 1; therefore, the chat panel 140shown in FIG. 11 contains the persistent virtual chat area for text chatinteractions occurring in connection with Zone 1. When the chat button98 is activated, on the other hand, the chat panel 140 opens to show achat interface for a persistent personal virtual area for interactionsbetween Art and a selected one of the communicants. Examples of personalvirtual areas are described in U.S. patent application Ser. No.12/509,658, filed Jul. 27, 2009.

The chat interface of the chat panel 140 includes a chat log area 142, atext box 144, and a Send button 146. The chat panel 402 also includes aminimap view of the current zone (zone 1) in which the user is present.In this example, the user may enter text messages in the text box 144and activate the Send button 146 to transmit the text messages to theother communicants who are present in the zone.

The user may enter text messages in the text box 144 and transmit thetext messages to the other communicants who are in the same zone byselecting the Send button 146. The chat log area 142 displays a log ofcurrent and optionally prior events that are associated with the currentzone. An exemplary set of events that may be displayed in the chat logarea 142 include: text messages that the user has exchanged with othercommunicants in the current zone; changes in the presence status ofcommunicants in the current zone; changes in the speaker and microphonesettings of the communicants in the current zone; and the status of theobject in the zone (discussed below), including references to anyapplications and data files that are shared in connection with theobjects. In the illustrated embodiments, the events are labeled by thecommunicant's name followed by content associated with the event (e.g.,a text message) or a description of the event.

The chat panel 140 provides a context for organizing the presentation ofthe events that are displayed in the chat log area 142. For example, inthe illustrated embodiment, each of the displayed events is labeled witha respective tag that visually correlates with the appearance of thesprite of the communicant that sourced the displayed event. Inparticular, each of the events that is sourced by a particular one ofthe communicants is labeled with a respective icon 148, 149, 150, 151having a visual appearance (e.g., color-code, or design pattern) thatmatches the visual appearance of that communicant's sprite. In thisexample, the color of the icons 148, 150 matches the color of the bodyof Art's sprite, and the color of the icon 149, 151 matches the color ofthe body of Beth's sprite.

In some examples, the platform enables a communicant to associateobjects in the zones of a virtual area with network resources, andmaintains those associations across sessions to provide zones withpersistent network resource associations that can be accessedimmediately upon entry into the zones. In these examples, an object(e.g., a view screen object) in a zone of a virtual area has aconfigurable uniform resource identifier (URI) property that acommunicant can configure to associate a network resource with theobject and thereby create “spatial bookmarks” for the network resourcesat the respective object locations in the zones of the virtual area. Inthis way, a communicant can customize a zone of a persistent virtualarea with any type of network accessible resources to suit anyparticular purpose and then share the network resources with othercommunicants in the zone. For example, communicants can associate viewscreen objects in a zone of a virtual area with respective cloud-basedservices that relate to a particular project or business function (e.g.,finance, accounting, software development, project management). Theplatform stores persistent records of the state of each zone of thevirtual area, including the service associations with objects and thecommunicant interactions (e.g., chat, recordings, shared documents) thatoccurred in the zone so that each time the communicants enter the zonethey can continue where they left off with single-click access to theservices that are relevant to the particular project or businessfunction associated with the zone. Being able to place and keep servicesrunning in a zone of a virtual area means that meetings start with liveapplication information (e.g., network resource information, storeddocuments, prior chat conversations, and recorded audio conversations)already in the zone, and can restart where communicants left adiscussion at the end of the previous meeting. Additional details ofexamples of processes for associating objects in a zone with networkresources are described in U.S. patent application Ser. No. 13/399,775,filed Feb. 17, 2012, and U.S. patent application Ser. No. 13/399,737,filed Feb. 17, 2012.

III. Conclusion

Other embodiments are within the scope of the claims.

1-31. (canceled)
 32. A method, comprising by apparatus of a virtual areacreation service that provides services enabling realtime synchronousconferencing communications between client network nodes: from a clientnetwork node, receiving a virtual area creation request and a list ofcommunicants; responsive to the request, automatically creating a newvirtual area, wherein the creating comprises associating the new virtualarea with attributes that designate the communicants in the list asmembers of the virtual area and that define a shared context forrealtime communications between copresent ones of the designatedcommunicants in the virtual area; and administering realtimecommunications of the designated communicants the virtual area.
 33. Themethod of claim 32, wherein: the creating comprises, based on the listof communicants, determining a number of zones corresponding torespective rooms in the virtual area and assigning each of one or moreof the designated communicants as an owner of a respective one of thezones who can control access to the respective zone by other non-ownercommunicants; and each zone is associated with a respectivevisualization and a respective set of one or more rules definingcommunication capabilities between communicants in the zone.
 34. Themethod of claim 32, wherein: the receiving comprises receiving a uniformresource identifier (URI) of a network resource; the creating comprisesassociating the new virtual area with the URI; and the administeringcomprises integrating a shared view of a network resource referenced bythe URI with the realtime communications between copresent ones of thedesignated communicants the virtual area.
 35. The method of claim 34,further comprising maintaining the association between the virtual areaand the URI across communication sessions in the virtual area.
 36. Themethod of claim 35, wherein the administering comprises enabling adesignated communicant to access the network resource immediately uponentry in the virtual area.
 37. The method of claim 34, wherein theassociating comprises associating the URI with an object in the virtualarea that facilitates screen sharing between copresent ones of thecommunicants in the virtual area.
 38. The method of claim 37, whereinthe object has a configurable URI property; and further comprisingreconfiguring the object with a different URI in response to a requestfrom a designated communicant in the virtual area.
 39. The method ofclaim 34, wherein the administering comprises maintaining persistentrecords of interactions of communicants in the virtual area, andtransmitting a view on the persistent records to a client network nodeof a designated communicant in the virtual area.
 40. The method of claim39, wherein the administering comprises providing to a client networknode of a designated communicant in the virtual area interface data fordisplaying in an interface the shared view of a network resource, therealtime communications between copresent ones of the designatedcommunicants the virtual area, and the transmitted view on thepersistent records.
 41. The method of claim 39, wherein the transmittedview comprises a history of text chat communications between respectiveones of the designated communicants in the virtual area.
 42. The methodof claim 39, wherein the transmitted view comprises a listing of currentand prior events associated with the virtual area.
 43. A method,comprising by apparatus of a virtual area creation service that providesservices enabling realtime synchronous conferencing communicationsbetween client network nodes: from a client network node, receiving avirtual area creation request and a uniform resource identifier (URI) ofa network resource; responsive to the request, automatically creating anew virtual area, wherein the creating comprises associating the newvirtual area with the URI and attributes that define a shared contextfor realtime communications between copresent communicants in thevirtual area; and administering realtime communications of communicantsthe virtual area, wherein the administering comprises integrating ashared view of a network resource referenced by the URI with therealtime communications between copresent communicants the virtual area.44. The method of claim 43, further comprising maintaining theassociation between the virtual area and the URI across communicationsessions in the virtual area.
 45. The method of claim 44, wherein theadministering comprises enabling a communicant to access the networkresource immediately upon entry in the virtual area.
 46. The method ofclaim 43, wherein the associating comprises associating the URI with anobject in the virtual area that facilitates screen sharing betweencopresent ones of the communicants in the virtual area.
 47. The methodof claim 46, wherein the object has a configurable URI property; andfurther comprising reconfiguring the object with a different URI inresponse to a request from a communicant in the virtual area.
 48. Themethod of claim 47, wherein the administering comprises maintainingpersistent records of interactions of communicants in the virtual area,and transmitting a view on the persistent records to a client networknode of a communicant in the virtual area.
 49. The method of claim 48,wherein the administering comprises providing to a client network nodeof a communicant in the virtual area interface data for displaying in aninterface the shared view of a network resource, the realtimecommunications between copresent communicants the virtual area, and thetransmitted view on the persistent records.
 50. The method of claim 48,wherein the transmitted view comprises a history of text chatcommunications between respective communicants in the virtual area. 51.The method of claim 48, wherein the transmitted view comprises a listingof current and prior events associated with the virtual area.